Users of modern computing systems are increasingly finding themselves in constantly-connected, high-speed networked environments. The Web continues to be a killer application, second only to email, on the Internet. Further, customers are increasingly using more than one computing device; a customer may have a desktop computer at home, one at work, and a constantly connected “smart phone”. Due to the confluence of these two trends, file management across these devices has become a problem.
Although modern devices are easily connected, they do not provide the customer a seamless environment; the customer must manually handle many aspects of that connection. With regards to file management, customers must manually move files between their devices using some protocol like email, ftp, or by posting them on the Web. These practices lead to problems that include:                The proliferation of redundant file copies. This proliferation creates a confusing environment where the customer is unclear where the “official” or newest version of a file exists.        The creation of an error-prone environment. Some documents, such as those associated with word processing and desktop publishing, externally reference other files. Copying such a document can break these references causing errors that the customer has to handle manually. An example of such a document is a desktop publishing document that contains a reference to an image. If that image file is not transferred along with the desktop publishing file, the image will appear as a broken link.        Unnecessary complexity. Because devices tend to have their own filing system, customers must manage a different filing model on each of his devices. For example, instead of having a single “Movies” folder, he may have to deal with many “Movies” folders, which may be in different locations on each of his devices. Each device may also have its own security model, further complicating the matter.        
That a customer has to manually move files around to ensure their accessibility on his devices is unnecessary, and is an indicator of a lack of customer-focused design in modern file systems. File systems in use today are direct offspring of systems used when graphical customer interfaces were nonexistent. Modern file system customer interfaces, such as Windows® Explorer and Mac OS X's Finder are just now starting to provide experiences that are more in line to a customer's workflow. Whereas, before, these interfaces were concerned with representing files with abstracted icons, the file's actual contents are becoming paramount in how files are organized and presented.
Problems still exist with how these newer customer interfaces are implemented. They are not completely integrated with applications, suffer from performance problems, and do not generally work well outside of a device's local file system.
There are several solutions to this problem that are in one way or another inadequate to the task:
Remote Desktop software allows a customer to remotely “see” his desktop. Remote desktop software screen-scrapes a remote machine's screen (a “server”) and displays it on a screen local to the customer (a “client”). Remote desktop gives a customer access to not only his files, but also to his applications. However, this approach requires that the host machine be turned on and connected to the internet at all times. Consequently, this approach would not be appropriate for mobile hosts such as laptops. Remote desktop does not use the resources of a local machine. For full accessibility, the customer would have to keep all files and application on the host machine as any files stored on a client are not guaranteed to be accessible.
Distributed File Systems, like remote desktop software, place data on an always-connected host machine. Unlike remote desktop software, the host machine is not one on which the customer performs computing tasks. The host machine is used as a storage mechanism, and any computation performed on that machine serves to supports its use as such. Distributed file systems generally provide the right functionality for customers to share files between their devices. However, distributed file systems are usually deployed as a shared resource; that is, other customers have access to it. Because of this sharing, a customer's files may be buried deep in a filing structure, and it may not always be immediately evident to customers what kind of access they have to a particular file. Further, to use a distributed file system, the customer must always be connected to it. Files stored on a distributed file system are generally inaccessible if the customer's machine is not connected to it, unless the customer has copied or moved the files to his machine's local hard drive. However, doing so immediately creates the problem of having two filing systems for the same file, creating a mental burden on the customer.
Additionally, accessing a file located on a distributed file system tends to be slower than accessing files on the local hard drive. Modern applications are usually written to assume that the files they access are located locally, and thus are not optimized to access remote files. When these applications are used with remote files, they can lose performance by an order of magnitude. This problem can be fixed by automatically caching often-used files on the local file system, and only synchronizing them when they have been changed. However, this separate synchronization step introduces another problem: because the synchronization process can be lengthy, the customer is never entirely sure if the file he is remotely accessing is the latest version of the file, versus an earlier one that has been marked to be updated. Further, the directory may not reflect the existence of the file at all until synchronization finishes.
FTP is similar to a distributed file system with regards to files being hosted on a remote server. However FTP generally does manifest as a “disk drive” on the customer's desktop; the customer must use special FTP client software to access an FTP server. It shares the same problem as distributed file systems, with the additional problem of weak integration with applications. Applications can generally write and read files directly to and from a distributed file system. This is not the case with FTP, as the customer has to manually use the client software to perform these operations as a separate task.
Email was originally invented for messaging. From the beginning, the model it employs to make files accessible remotely is necessarily inefficient. Email's model for making files accessible is in the form of an email “attachment”. Attachments are so named because they piggy-back on a message sent from one customer to another. A customer can make a file remotely available using email by attaching the file to an email and sending it to himself. He can then retrieve the file from a remote location by accessing the message on the email server. Email used in this way is even worse than FTP as the process is even more manual: a customer must find the message containing the file before he can even access it. Further, the location in which the attachment lives is read only. If the customer, for example, were to open the file, change it, then save it back out, the results would be ambiguous to the user because the email application, not the user, specified its location. Usually, the saved file would end up buried in an email file cache in an undisclosed area of the file system.
Flash Drives and External Disk Drives, although seemingly the most “primitive” way to ensure file availability, avoid all the problems related to network latency. However, these devices must be physically connected to the computer on which the files will be accessed. These restrictions preclude the customer from employing several effective work-flows including: using more than one computer to complete a single task (the files can only be accessed on one computer) and setting up an automated backup (the computer running the backup can't guarantee that the storage device will be connected come backup time). Further, to ensure full availability of the files, the customer must carry the device with them at all times, and must follow the associated protocols for mounting and dismounting the device.
Other problems with the prior art not described above can also be overcome using the teachings of embodiments of the present invention, as would be readily apparent to one of ordinary skill in the art after reading this disclosure.